\section{Le Méta-Modèle \kwsoa}\label{sub:soa}

\kwsoa{} (Service Oriented Architecture) - ou Architecture Orientée Services - est une forme d'architecture englobant le concept de Services et leurs interactions dans une application. Le Méta-Modèle \kwsoa{} sur lequel nous nous sommes basés représente ce type d'architecture au travers d'un système basé sur les Composants. Concrêtement, un modèle basé sur le M2 \kwsoa est constitué de Composants. Chaque Composant peut possèder des Services dont des Interfaces permettent de communiquer avec l'extérieur. Ces Interfaces définissent une ou plusieurs Opérations, chaque opération étant caractérisée par un ensemble de Paramètres d'entrée et de sortie. Ces paramètres peuvent être des types relativement basiques (Integer, String, \dots) mais également des \guim{Entity} complexes, comme des informations complètes sur les utilisateurs, ou sur des produits.	

\begin{figure}[htb]
  \centering
  \includegraphics[scale=.3]{img/SOA.eps}
  \caption{Métamodèle SOA}
  \label{fig:soa}
\end{figure}

\subsection{La notion de \kwsoa{} dans \kwplay{}}

\kwplay{} et son achitecture en MVC ne proposent pas d'implémentation concrête de la notion de Services. 
Nous avons donc fait le choix de déporter ces derniers dans des classes externes de type Singleton, ce qui permet de faire appel aux différents Services depuis n'importe quel Controleur de \kwplay{} (ex : \textit{Services.getAKindOfService().do\_service()}).
Cela permet de séparer les différents concepts sans pour autant remettre en cause l'architecture originelle de \kwplay{}.

\subsection{Conception du modèle}

La conception du modèle SOA pour le contexte de notre magasin en ligne a été assez simple à convenir : Pour chaque cas d'utilisation ou action, nous avons modélisé un certain nombre d'opérations basiques. Ces opérations ont été réunies dans différents Composants et Services, en fonction de leur contexte, mais également en fonction du type d'utilisateur susceptible de faire appel à ces opérations.
Les types de Services que nous avons représenté dans notre Modèle SOA sont regroupés dans les Composants suivants :
\begin{itemize}
\item \textbf{UserManager :} Contient un Service de gestion des utilisateurs/clients du site, accessible depuis l'intérieur de l'application uniquement. Ce Service sera utilisé pour contrôler l'inscription et l'authentification des utilisateurs du site.
\item \textbf{ProductsManager :} Contient des Services de gestion des produits vendus sur le site. Ces Services pourront - pour la plupart - être appelables depuis l'extérieur. On distinguera deux interfaces différentes pour distinguer le traitement des informations relatives aux produits (label, description), et les ventes en elles-mêmes (prix, stock). Cela permet d'assigner des propriétés différentes pour deux types de Services, ce qui faciliterait une gestion des droits d'accès.
\item \textbf{ShopManager :} Tout comme l'\textbf{UserManager}, les Services du \textbf{ShopManager} seront destinés à une utilisation interne à l'application. Il sera utilisé lors de l'ajout des produits au \guim{Panier} d'un client, et pour valider les achats. C'est également ce Composant qui pourra faire le lien avec les Services de paiements externes (non-implémentés dans notre prototype).
\end{itemize}
%Ainsi, les opérations consistant à inscrire ou connecter un utilisateur ont été regroupées au sein d'un \textit{AuthentificationManager} accessible uniquement par l'application en elle-même. 

% Ici schéma du Modèle SOA (je m'en charge aussi)

\subsection{Génération du code des services}

\subsubsection{Séparation interfaces/implémentations}

Afin d'assurer une souplesse de l'application, la génération des différents Services systématiquement découpée en deux parties :
\begin{itemize}
\item Des interfaces, contenant les signatures des différentes opérations.
\item Des classes d'implémentation, liées à ces interfaces.
\end{itemize}	

Les classes d'implémentation sont générées avec le code des différentes opérations, lorsque celles-ci sont basiques et facilement interprêtables (récupérer/éditer/détruire une Entité). Dans tous les cas, des balises \guim{User Code} sont insérées afin de laisser libre choix à l'utilisateur pour les détails de l'implémentation.\\
Cette séparation interfaces/implémentations peut également permettre d'avoir plusieurs types d'implémentation de Services pour une même interface.\\
Nous avons implémenté les différentes classes de Services comme étant des Singleton. Il est ainsi possible d'appeler un Service depuis n'importe quel endroit de l'application avec une syntaxe du type \textit{Services.getMonrService().faireMonTravail()}.

\subsubsection{Plus loin avec SOA : Les webservices}

Ils nous a été proposé d'ajuster également les moyens d'accès aux différents Services, qui peuvent être à usage interne à l'application, ou bien pouvant communiquer avec l'extérieur.
Nous avons ainsi mis en place des solutions permettant d'appeler certains Services depuis l'extérieur, sans passer par l'interface du site Web.
Par exemple, il devrait être possible d'appeler certains Services depuis un logiciel de gestion, pour la gestion des ventes des produits, des factures, ou des comptes utilisateurs, ou pour collecter des informations.

Pour ce faire, nous avons procédé à la mise en place d'un service de type \textit{REST (REpresentational State Transfer)}.
Le principe est d'utiliser le format des requêtes HTTP - qui peuvent être de type \textit{GET/POST/PUT/DELETE} - afin d'interprêter certaines d'entre-elles comme étant des requêtes liées à des Services.
Nous avons donc implémenté un tel système en configurant, pour chaque opération accessible depuis l'extérieur (selon le Modèle), des Routes spécifiques déclenchant l'exécution des opérations - c'est à dire des appels aux services générés précédement -, et retournant un résultat au format \textit{JSON}.

% Être + ou - verbeux et ajouter un schéma (style le premier qui illustrait Play!, mais avec le concept de Services internes et de WebServices)

\clearpage
